Distributed computer system enhancing a protocol service to a highly available service

ABSTRACT

One embodiment of the present invention provides a distributed computer system comprising a group of nodes, said group of nodes having a first and a second node adapted to act as current monitor nodes, each node of the group of nodes having an identifier and a management layer being informed which node currently acts as the current monitor node. The first and second node each include a protocol server adapted to associate and to send an address to a node requesting an address in the group of nodes, and a memory adapted to store an association address-identifier of a node requesting an address. The protocol server is further capable of requesting the management layer of a node for an indication informing if said node acts as the current monitor node, and attributing, to the current monitor node, the ownership of a list of associations, said list comprising associations of the memory.

RELATED APPLICATION

[0001] This application hereby claims priority under 35 U.S.C § 119 to French patent application No. 0201228, filed Feb. 1, 2002, entitled, “Distributed Computer System Enhancing a Protocol Service to a Highly Available Service,” Attorney Docket No. SUN Aff. 31.

RELATED ART

[0002] The invention relates to a distributed computer system, for example a distributed computer system providing an extensible distributed software execution environment. Such an environment is a software platform, which may be intended for management and control applications for network components. Such a platform is composed of a group of cooperating nodes, also called a cluster, some nodes having hard disk and designated as diskfull and other nodes having no hard disk and designated as diskless. Such nodes use a standard network protocol, e.g. the DHCP protocol (Dynamic Host Configuration Protocol) described in the RFC 2131, March 1997, to provide administration information from diskfull nodes, called server nodes, to requesting nodes being possibly diskless nodes, called client nodes. Used in the Internet, the DHCP protocol provides IP address, Time Zone, network routing, mail, printing information and others various resources location to requesting nodes.

[0003] Such a platform may have to be highly available. Thus, limits of the DHCP protocol concerning management of nodes appear in an environment having e.g. various server nodes, nodes needing to re-boot or being detected as failed or nodes having redundant links.

[0004] A general aim of the present invention is to provide advances towards high availability.

[0005] The invention concerns a distributed computer system comprising a group of nodes, said group of nodes having a first and a second node adapted to act as current monitor nodes, each node of the group of nodes having an identifier and a management layer being informed which node currently acts as the current monitor node. Each first and second node comprises,

[0006] a protocol server adapted to associate and to send an address to a node requesting an address in the group of nodes,

[0007] a memory adapted to store an association address-identifier of a node requesting an address. The protocol server is further capable of

[0008] requesting the management layer of a node for an indication informing if said node acts as the current monitor node,

[0009] attributing, to the current monitor node, the ownership of a list of associations, said list comprising associations of the memory of first node shared with associations of the memory of second node.

[0010] The invention also concerns a method of managing a distributed computer system having a group of nodes, each node having an identifier, and comprising a first and a second node being adapted to act as the current monitor node of the group of nodes, comprises the following steps:

[0011] a. requesting for an indication informing which one of the first or the second node acts as the current monitor node,

[0012] b. attributing, to the current monitor node, the ownership of a list of associations address-identifier of nodes, this list comprising the associations from the first and second nodes,

[0013] c. responsive to a reception of a request for an address of a requesting node in the first and the second nodes, associating and sending an address to the requesting node from the current monitor node,

[0014] d. repeating steps a. to step c.

[0015] Other alternative features and advantages of the invention will appear in the detailed description below and in the appended drawings.

BRIEF DESCRIPTION OF THE FIGURES

[0016]FIG. 1 is a general diagram of a distributed computer system comprising a diskfull node and a diskless node.

[0017]FIG. 2 is a general diagram of a distributed computer system having redundant networks.

[0018]FIG. 3 is a functional diagram of a node using a network protocol according to the invention.

[0019]FIG. 4 is an architecture of a protocol as known.

[0020]FIG. 5 is a functional diagram of a distributed computer system using a network protocol module according to an embodiment of the invention.

[0021]FIG. 6 is a table of IP addresses stored according to the network protocol module of an embodiment of the invention.

[0022]FIG. 7 is a flow-chart of the monitor node according to an embodiment of the invention.

[0023]FIG. 8 is a flow-chart of the management of assignment of addresses according to an embodiment of the invention.

[0024]FIG. 9 is a flow-chart of the address synchronization according to an embodiment of the invention.

DETAILED DESCRIPTION

[0025] The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

[0026] The data structures and code described in this detailed description are typically stored on a computer readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. This includes, but is not limited to, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs) and DVDs (digital versatile discs or digital video discs), and computer instruction signals embodied in a transmission medium (with or without a carrier wave upon which the signals are modulated). For example, the transmission medium may include a communications network, such as the Internet.

[0027] A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright and/or author's rights whatsoever.

[0028] Additionally, the detailed description is supplemented with the following Appendices:

[0029] Appendix A contains specific data structures and API functions;

[0030] Appendix B contains extracts of code according to an embodiment of the invention.

[0031] These Appendices are placed apart for the purpose of clarifying the detailed description, and of enabling easier reference. They nevertheless form an integral part of the description of embodiments of the present invention. This applies to the drawings as well.

[0032] This invention also encompasses embodiments in software code, especially when made available on any appropriate computer-readable medium. The expression “computer-readable medium” includes a storage medium such as magnetic or optic, as well as a transmission medium such as a digital or analog signal.

[0033] This invention may be implemented in a network comprising computer systems. The hardware of such computer systems is for example as shown in FIG. 1, where in the computer system 10:

[0034]1-10 is a processor, e.g. an Ultra-Sparc (SPARC is a Trademark of SPARC International Inc);

[0035]2-10 is a program memory, e.g. an EPROM for BIOS;

[0036]3-10 is a working memory for software, data and the like, e.g. a RAM of any suitable technology (SDRAM for example); and

[0037]7-10 is a network interface device connected to a communication medium 8, itself in communication with other computers such as computer system 11. Network interface device 7-10 may be an Ethernet device, a serial line device, or an ATM device, inter alia. Medium 8 may be based on wire cables, fiber optics, or radio-communications, for example.

[0038] The computer system 10 may be a node amongst a group of nodes in a distributed computer system. The other node 11 shown in FIG. 1 comprises the same components as node 10, the components being designated with the suffix 11. The node 11 further comprises a mass memory 4-11, e.g. one or more hard disks.

[0039] Thus, node 10 is considered as a diskless node and node 11 is considered as a diskfull node.

[0040] Data may be exchanged between the components of FIG. 1 through a bus system 9-10, respectively 9-11, schematically shown as a single bus for simplification of the drawing. As is known, bus systems may often include a processor bus, e.g. of the PCI type, connected via appropriate bridges to e.g. an ISA bus and/or an SCSI bus.

[0041]FIG. 1 depicts two connected nodes.

[0042]FIG. 2 shows an example of a group of nodes noted N* arranged as a cluster K. The cluster has a master node NM, a vice-master node NV and other nodes N2, N3 . . . Nn-1 and Nn. The qualification as master or as vice-master should be viewed as dynamic: one of the nodes acts as the master (resp. Vice-master) at a given time. However, for being eligible as a master or vice-master, a node needs to have the required “master” functionalities. A node being diskfull is considered to have at least partially these master functionalities.

[0043] References to the drawings in the following description will use two different indexes or suffixes i and j, each of which may take anyone of the values: {M, V, 2 . . . n}, n+1 being the number of nodes in the cluster.

[0044] In FIG. 2, each node Ni of cluster K is connected to a first network 31 via links L1-i. This network 31 is adapted to interconnect this node Ni with another node Nj through the link L1-j. If desired, the Ethernet link is also redundant: each node Ni of cluster K is connected to a second network 32 via links L2-i. This network 32 is adapted to interconnect this node Ni with another node Nj through the link L2-j. For example, if node N2 sends a packet to node Nn, the packet may be therefore duplicated to be sent on both networks. The mechanism of redundant network will be explained hereinafter. In fact, the foregoing description assumes that the second network for a node may be used in parallel with the first network.

[0045] Also, as an example, it is assumed that packets are generally built throughout the network in accordance with a transport protocol and a presentation protocol, e.g. the Ethernet Protocol and the Internet Protocol. Corresponding IP addresses are converted into Ethernet addresses on Ethernet network sections.

[0046] In a more detailed exemplary embodiment and according to the Internet Protocol, a packet having an IP header comprises identification data as the source and destination fields, e.g. according to RFC-791. The source and destination fields are the IP address of the sending node and the IP address of the receiving node. It will be seen that a node has several IP addresses, for its various network interfaces. Although other choices are possible, it is assumed that the IP address of a node (in the source or destination field) is the address of its IP interface 100 (to be described).

[0047]FIG. 3 shows an exemplary node Ni, in which the invention may be applied. Node Ni comprises, from top to bottom, applications 13, management layer 11, network protocol stack 10, and Link level interfaces 12 and 14, respectively connected to network links 31 and 32. Applications 13 and management layer 11 can be implemented, for example, in software executed by the node's CPU 1. Network protocol stack 10 and link level interfaces 12 and 14 can likewise be implemented in software and/or in dedicated hardware such as the node's network hardware interface 7. Node Ni may be part of a local or global network; in the foregoing exemplary description, the network is an Ethernet network, by way of example only. It is assumed that each node may be uniquely defined by a portion of its Ethernet address. Accordingly, as used hereinafter, “IP address” means an address uniquely designating a node in the network being considered (e.g. a cluster), whichever network protocol is being used. Although Ethernet is presently convenient, no restriction to Ethernet is intended.

[0048] Thus, in the example, network protocol stack 10 comprises:

[0049] an IP interface 100, having conventional Internet protocol (IP) functions 102, and a multiple data link interface 101,

[0050] above IP interface 100, message protocol processing functions, e.g. an NFS function 104 and/or a DHCP function 105. This DHCP function is adapted to use the DHCP protocol as described in the RFC 2131, March 1997.

[0051] Network protocol stack 10 is interconnected with the physical networks through first and second Link level interfaces 12 and 14, respectively. These are in turn connected to first and second network channels 31 and 32, via couplings L1 and L2, respectively, more specifically L1-i and L2-i for the exemplary node Ni. More than two channels may be provided.

[0052] Link level interface 12 has an Internet address <IP_(—)12> and a link level address <<LL_(—)12>>. Incidentally, the doubled triangular brackets (<<. . . >>) are used only to distinguish link level addresses from global network addresses. Similarly, Link level interface 14 has an Internet address <IP_(—)14>and a link level address <<LL_(—)14>>. In a specific embodiment, where the physical network is Ethernet-based, interfaces 12 and 14 are Ethernet interfaces, and <<LL_(—)12>>and <<LL_(—)14>> are Ethernet addresses.

[0053] IP functions 102 comprise encapsulating a message coming from upper layers 104 or 105 into a suitable IP packet format, and, conversely, de-encapsulating a received packet before delivering the message it contains to upper layer 104 or 105.

[0054] In redundant operation, the interconnection between IP layer 102 and Link level interfaces 12 and 14 occurs through multiple data link interface 101. The multiple data link interface 101 also has an IP address <IP_(—)10>, which is the node address in a packet sent from source node Ni.

[0055] References to Ethernet are exemplary, and other protocols may be used as well, both in stack 10, including multiple data link interface 101, and/or in Link level interfaces 12 and 14.

[0056] Furthermore, where no redundancy is required, IP layer 102 may directly exchange messages with anyone of interfaces 12,14, thus by-passing multiple data link interface 101.

[0057] It will be appreciated that layers 10 and 11 comprise components to provide a highly available link with application layer 13 running on the node. The management layer 11 also comprises a management and monitor entity of the node in the cluster, e.g. a Cluster Membership Monitor (CMM).

[0058]FIG. 4 illustrates an architecture of a DHCP (Dynamic Host Configuration Protocol) function or service which may have a multi-layered architecture. A diskfull node may have such a DHCP function adapted to receive DHCP request from diskless nodes.

[0059] The DHCP multi-layered architecture 116 is composed of a service provider layer 126, a private layer 136 and an application/service provider layer 146.

[0060] As described in Appendix A-I-1, the service provider layer 126 implements the service provider layer API functions described in Appendix A-I-4, exported by DHCP public modules and consumed by the private layer. Moreover, in Appendix A-I-2, A-I-3 this service provider layer defines the data structure stored in portions of disk accessible from the DHCP function, these portions of disk may be called “container”. There may be two types of containers called dhcp containers, the dhcptab container and the dhcp network container. The dhcptab container contains DHCP configuration data. There is only one instance of a dhcptab container maintained in the DHCP service. There can be any number of dhcp network containers, e.g. one for each network supported by the DHCP service. dhcp network containers contain records.

[0061] The private layer 136 implements framework-related functions for locating and loading public modules, and provides “consumers API functions” used by consumers of the DHCP service data.

[0062] The Application/service provider layer 146 contains all consumers of DHCP service data such as the DHCP server, the administration tools.

[0063] A boot of a node is hereinafter describes.

[0064] When a new node is inserted in the system at initialization time or at any other time, the node is booted according to its software load configuration parameters. Particularly, this boot enables a diskless node to obtain its address from a diskfull node. In an embodiment, other addresses, e.g. the addresses of the various links of the diskless node, may be calculated from the diskless node's address as described hereinafter. In another embodiment, these other addresses may be also obtained during the boot of a diskless node.

[0065] At initialization time, each node executes an initialization software providing various capabilities such as low level hardware configuration, low level hardware tests, operating system loading configuration, boot file configuration. On Sun hardware, such software may be called Open Boot Prom (OBP).

[0066] According to the configuration of this initialization software (e.g. OBP), it launches a program to allow diskfull nodes to boot from their local disk or from the network, and to allow diskless nodes to boot from the network only. To boot from the network means to boot from the disk of a remote diskfull node in the network.

[0067] In the context of this invention, boot of diskless nodes is particularly considered. When a diskless node boots, its initialization software (e.g. OBP) sends a broadcast request (e.g. DHCP discover) containing an identifier of the node, e.g. its Ethernet address, a board serial number or a MAC address, according to a particular protocol, e.g. DHCP. Thus, all nodes may receive this request. As seen, a diskfull node has a DHCP server adapted to reply to this request by providing

[0068] its address as the DHCP server,

[0069] the file path name of the diskfull node to download the default boot file on the diskless node.

[0070] This DHCP server replies also by providing the address, e.g. IP address, of the diskless node. Each data or resources may be contained in portions of disk called DHCP containers.

[0071] Several diskfull nodes have a DHCP server adapted to reply to a request of a diskless node, called a client's request. A function exported by a public module of the service provider layer of DHCP allows two DHCP servers to run on two separated diskfull nodes and sharing the same DHCP container.

[0072] A diskfull node which reply to the request is considered as the owner diskfull node of the reply for all the associated resources. Problems hay occur when this owner diskfull node fails : the resources owned by this node are unavailable until re-boot of this node. Thus, some diskless nodes may be blocked and/or may be unabled to boot when this owner diskfull node fails.

[0073] Another limit resides in the fact that the DHCP servers propose, at first boot of a node, a permanent address assignment for client nodes. If a node fails and the node is replaced by another with another identifier, the permanent IP address and the associated files in the DHCP containers are not re-assignable and are lost for the cluster.

[0074] The DHCP protocol has still another limit for nodes comprising redundant network interfaces, such as redundant link level interfaces. Thus, the DHCP server assigns independently the address of a first link level interface and of a second link level interface of the same client node.

[0075]FIG. 5 illustrates a partial cluster comprising two diskfull nodes. As herein above described, diskless nodes have the same structure as a diskfull node without a memory 4 containing containers 41 and 42 as described hereinafter.

[0076] Thus, each diskfull node comprises a new DHCP function 106, also called the new DHCP server 106, composed of a core DHCP server 1061, a configuration file tool 1062 and a public module 1063 called e.g. NHRBS public module (Sun Netra Highly Reliable Boot Service). The core DHCP server 1061 corresponds to the known DHCP architecture of FIG. 4. Thus, the configuration file tool 1062 may be part of the Application/Service Provider layer as an administration tool and the public module 1063 may be part of the Service Provider layer.

[0077] The configuration file tool 1062 is adapted to configure the core DHCP server so as to use the public module 1063. Then, other DHCP administration tools, as this configuration file tool 1062, may also use the NHRBS public module 1063. This configuration file tool 1062 is adapted to generate a main configuration file in which are given the following information e.g. the name of the public module 1063 to use, the path name of the directory containing the various data containers, the network interfaces to monitor. Moreover, this configuration file tool if adapted to set or to modify values in the main configuration file. An example of a main configuration file generated by the configuration file tool is in Appendix A-II. In this example, the main configuration file containing DHCP service configuration parameters is stored in /etc/inet/dhcpsvc.conf, the RESOURCE line indicates the use of the NHRBS public module called SUNWnhrbs, the path name PATH=/SUNWcgha/remote/var/dhcp indicates the directory containing the various data containers and the INTERFACES line indicates the network interfaces to monitor.

[0078] The new public module 1063 is a dynamic library automatically loaded at run-time by the core DHCP server 1061.

[0079] The DHCP server 106 is linked to a memory 4 having containers e.g. containers 41, 42, via a NFS server 104 (Network file system). The configuration file tool 1062 indicates the link level interfaces of the diskfull node to which the DHCP server is connected to and that this DHCP server monitors. Thus, one container is designated for each link level interface monitored by the DHCP server. This container is called the network container. It may contain the data corresponding to request received at the link level interface of the diskfull node. Its address may indicate this link level interface address. Indeed, there may be one network container per sub-net managed by the DHCP server. Typically, a single server running on a system equipped with two network interfaces (hme0 and hme1 for example on the Netra systems), can manage two DHCP network containers, one for each interface. In the example of Appendix A-II, the network containers used by the SUNnhrbs module are named: SUNWnhrbsN_A_B_C_D where:

[0080] N is the version of the public module managing the container. (e.g. 1 for NHAS 2.0).

[0081] A_B_C_D is the classical ASCII decimal representation for the sub-net corresponding to the network interface,

[0082] For example, if interface hme0 is connected to sub-net 10.1.1.0 and hme1 to sub-net 10.1.2.0, the network containers will be named: SUNWnhrbs1_(—)10_(—)1_(—)1_(—)0 and SUNWnhrbs1_(—)10_1 _(—)2_(—)0. The content of the network containers used by SUNWnhrbs may be compatible with the ones used by the public module of the service provider layer.

[0083] These network containers 41, 42 are used by the new public module 1063 to store data associated in a table T as illustrated in FIG. 6.

[0084] The network container 41 may contain entries having different fields such as:

[0085] an C-IP field containing the IP address managed by the DHCP server,

[0086] an C-ID field containing, when the IP address is assigned to a client node, the identifier of the client node, e.g. the MAC address of said node,

[0087] an S-IP field containing the IP address of the DHCP server owning this entry, e.g. the server which manages it,

[0088] a flag field being a bit-field containing information concerning the current status for the related entry, e.g. the “type of DHCP lease”. The term “lease” designates a given time enabling the use of the C_IP address for a node. The “lease” may be dynamic, meaning that at the end of this given time, the C_IP address corresponding to the “lease” may be renewed if needed. The “lease” may also be permanent, meaning the C_IP address is always assigned to a same node.

[0089] Other fields may be added to specify other data related to the entry.

[0090] The content of these network containers 41, 42 may be rendered compatible with the containers used for other modules. The dhcp network container and the dhcptab container are configured by the configuration file tool 1062.

[0091] An example of dhcp network container configured by the configuration file tool is given in Appendix A-Ill for the sub-network 10_(—)1_(—)1_(—)0. As described hereinafter, the entry concerning the IP address 10.1.1.10 is manually bound to the node which identifier is 01080020F996DA. An example of dhcptab container is given in Appendix A-IV. This dhcptab container contains definition for macro's and symbols which can be applied to one or more network container entries. This container is not modified by the configuration file tool 1062 of the invention.

[0092] The DHCP containers may be dynamically updated by the DHCP server at run-time, e.g. when entries are assigned to client nodes, when the lease is renewed, and by configuration files if configuration changes.

[0093] In an embodiment, all the entries are configured for permanent lease for nodes of the cluster. The flag can designate e.g. a permanent lease.

[0094] Reverting to FIG. 5, the containers of diskfull nodes may be shared by at least two diskfull nodes, the master node and the vice-master node. The diskfull nodes may use a NFS network (Network File System).

[0095] Amongst diskfull nodes, the master NM and vice-master NVM nodes of the cluster are to be designated initially and at every boot of the system. Moreover, when the management layer 11-NM detects the master node NM as failed, the vice-master NVM is designated as the new master node of the cluster. The management layer 11-NVM detects the vice-master node as the current master node. The DHCP server of a node is advantageously linked to the management layer of the node.

[0096] Indeed, at initialization time, the NHRBS public module of each diskfull node creates a thread enabling the new DHCP server to be connected to the management layer services to receive cluster membership notifications (MASTER-ELECTED, MEMBER-JOINED, MEMBER-LEFT). When such a notification is received, the new public module 1063 is adapted to take the appropriate action as described in Appendix B-II and hereinafter in the different methods.

[0097] A first method of an embodiment of the invention is illustrated in FIG. 7 when a client node boots and requests for an IP address (operation 400).

[0098] Each diskfull node receives the broadcast request (e.g. DHCP DISCOVER) in its DHCP server (operation 410). Each diskfull node has its,new DHCP server using the new public module to order the management layer to checks the node's role (operation 420). If the current diskfull node is not the current master node (operation 430), then the flow chart ends. If the current diskfull node is the current master node (operation 430), the table of entries may be modified by the new DHCP server using the new public module to indicate the monitorship of the current master node (operation 450). Thus, the new DHCP server using the new public module of the master current node changes the table of entries by setting all the server IP addresses (S-IP) as being the master node IP-address, such as getting the ownership of all the IP addresses configured. In an embodiment, the master node IP-address may be the multiple data link interface address of the master node. Thus, only the new DHCP server of the current master node replies to the broadcast request by providing the administration data comprising the required IP address C-IP to the node requesting an address (operation 460).

[0099] The diskfull node being the vice-master node only receives the broadcast requests and the management layer notifications without replying when receiving them. This process and its corresponding components enables no IP-address (C-IP) to belong to a failed diskfull node.

[0100] At initialization time, the ownership of the current master node is done in Appendix B-I which corresponds to an extract from an open_dn( ) API function. The IS_MASTER_INIT_DN_DONE macro checks if master node specific initialization is already done, while the macro IS_MASTER_NODE checks if the current node is the master node. The set_ownership_dn( ) function searches in the given DHCP network container for entries not owned by the current Master node. For every entry found, the entry is updated to be owned by the current Master node.

[0101] In Appendix B-II-1, when a MASTER-ELECTED notification is received, the management layer of the node checks the node's role (operation 420). Thus, the table of entries may be modified by the new DHCP server using the new public module to indicate the monitorship of the current master node (operation 450).

[0102] A second method of an embodiment of the invention is now illustrated with the flow chart of FIG. 8.

[0103] When a node is detected as a failed node (MEMBER-LEFT) (operation 510), the flag value corresponding to the IP-address of said failed node is checked (operation 520). If said flag designates a “manual” value, the current master node does no action for this node (operation 530). This means a user may change manually, e.g. the hardware board and the corresponding identifier. If said flag does not designate a “manual” value, the current master node clears the node identifier from the table and the flag of said entry (operation 540). This operation liberates the resources in the containers corresponding to this entry.

[0104] In operation 510, the node may be detected as failed:

[0105] when the management layer sends a notification designating a node has left the cluster (shutdown or re-boot),

[0106] when the server has provided data to the node requesting to join the cluster and has expected the node to join the cluster in an amount of time; this time has expired; the new public module according to the invention has checked the node presence and has decided the node has failed.

[0107] Each time a node leaves the cluster (reboot or shutdown), the notification ‘MEMBER LEFT’ is received from the management layer by the DHCP server. In this case, the DHCP server (more particularly the NHRBS public module) clears any lease (which may be pending time-out) and proceeds to the notification as described in Appendix B-11-3.

[0108] A third method of an embodiment of the invention is now illustrated with the flow chart of FIG. 9.

[0109] The IP address is composed of 4 octet, e.g. 100.1.1.50 according to the version v4:

[0110] first octet and second octet 100.1 designate the cluster to which the nodes belongs,

[0111] third octet 1 designates the sub-network used by the node,

[0112] fourth octet 50 designates the node and is called the hostnumber.

[0113] When receiving a request from a client node for an IP address allocation (operation 600) (MEMBER-JOINED), the master node provides an IP address (C-IP) from a first container for a first link level interface of the client node. If the client node accepts the IP address (operation 610), a mechanism is adapted to synchronize the IP address allocation for both containers. Thus, the second container may be bound to provide a given IP address to the second link level interface of the client node. The second address is calculated by changing the third octet to designate the second network. This address has the same hostnumber as in the IP address of the first link level interface and designates a different sub-net than the IP address of the first link level interface. The first and second containers are updated in a synchronous way (operation 620).

[0114] At operation 600, when a client node requesting an address (for example at or after a reboot time), the master node tries to provide only an IP address (C-IP). The mechanism may use an internal cache of managed IP addresses. This cache is used to keep track of the IP address provided to the client node. Thus, the internal cache may provide the same IP address between several re-boots to a given node.

[0115] In the case of liberating an IP address, the node which had this IP address may be assigned to the same IP address when it re-boots. This can happen when no other nodes have taken this IP address during the interval between the liberation of address and the re-boot of the node.

[0116] The synchronization mechanism at operation 620 is also used if the node left the cluster for example. The DHCP server (using the NHRBS public module) is responsible for maintaining DHCP network containers coherency. As stated above, when an entry is assigned to a first link of a node (or freed) in one network container, an entry has to be assigned to the second link of the same node (or freed) in the other network container.

[0117] The DHCP server (using the NHRBS public module) introduces synchronization methods between the network containers. The word “coherency” implies the synchronization mechanism.

[0118] Thus, the third octet may be the octet 1 to designate the first link level interface, the octet 2 to designate the second link level interface, the octet 3 to designate that first and second link level interfaces are used in a redundant way. In the last case, the address is divided into two addresses designating the first and second link level interfaces.

[0119] The invention is not limited to the herein above-described features.

[0120] Thus, other network containers may be used if other link level interfaces are provided for a node.

[0121] The foregoing descriptions of embodiments of the present invention have been presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the present invention. The scope of the present invention is defined by the appended claims. 

What is claimed is:
 1. A distributed computer system comprising a group of nodes, said group of nodes having a first and a second node adapted to act as current monitor nodes, each node of the group of nodes having an identifier and a management layer being informed which node currently acts as the current monitor node, each first and second node comprising: a protocol server adapted to associate and to send an address to a node requesting an address in the group of nodes; and a memory adapted to store an association address-identifier of a node requesting an address; wheren the protocol server being further capable of, requesting the management layer of a node for an indication informing if said node acts as the current monitor node, attributing, to the current monitor node, the ownership of a list of associations, said list comprising associations of the memory of first node shared with associations of the memory of second node.
 2. The distributed computer system of claim 1, wherein the protocol server of the current monitor node is adapted to permanently associate an address to a node requesting an address.
 3. The distributed computer system of claim 2, wherein the protocol server is adapted to liberate the permanently associated address when the management layer of the current monitor node detects as down said node.
 4. The distributed computer system of claim 3, wherein the protocol server of the current monitor node is further adapted to designate an association of address-identifier of a node in the list to permit manual change of the identifier in case of change of the identifier of said node.
 5. The distributed computer system of claim 4, wherein the protocol server of the current monitor node is adapted to associate a first address to a first link of a node and to associate a second address to a second link of this node, first and second addresses comprising four octet having three identical octet to designate the same node, the fourth octet being adapted to designate the first and second links.
 6. The distributed computer system of claim 5, wherein the protocol server of the current monitor node is adapted to associate a third address to a node comprising four octet with three identical octet to first and second addresses, said third address indicating first and second addresses are used in a redundant manner.
 7. The distributed computer system of claim 1, wherein the protocol server is adapted to cooperate with an internal cache in order to store the address provided to the requesting node and in order to supply this address responsive to a request of the same requesting node after a re-boot.
 8. The distributed computer system of claim 1, wherein the protocol server comprises an address management module adapted to provide the address services as claimed in the preceding claims.
 9. The distributed computer system of claim 1, wherein the protocol server is capable to be configured by a configuration file tool so as to use the address management module.
 10. A method of managing a distributed computer system having a group of nodes, each node having an identifier, and comprising a first and a second node being adapted to act as the current monitor node of the group of nodes, wherein the method comprises the following steps: a. requesting for an indication informing which one of the first or the second node acts as the current monitor node; b. attributing, to the current monitor node, the ownership of a list of associations address-identifier of nodes, this list comprising the associations from the first and second nodes; c. responsive to a reception of a request for an address of a requesting node in the first and the second nodes, associating and sending an address to the requesting node from the current monitor node; and d. repeating steps a. to step c.
 11. The method of claim 10, wherein step c. comprises permanently associating an address to a node requesting an address.
 12. The method of claim 11, wherein step c. comprises liberating this address when the current monitor node detects as down said node.
 13. The method of claim 12, wherein step c. further comprises designating an association of address-identifier of a node in the list to permit manual change of the identifier in case of change of the identifier of said node.
 14. The method of claim 13, wherein step c. further comprises associating a first address to a first link of a node and associating a second address to a second link of this node, first and second addresses comprising four octet having three identical octet to designate the same node, the fourth octet being adapted to designate the first and second links.
 15. The method of claim 14, wherein step c. comprises associating a third address to a node comprising four octet with three identical octet to first and second addresses, said third address indicating first and second addresses are used in a redundant manner.
 16. The method of claim 1, wherein step c. comprises storing the address provided to the requesting node and supplying this address responsive to a request of the same requesting node after a re-boot.
 17. The method of claim 1, wherein the current monitor node is the master node of the group of nodes.
 18. A computer-readable storage medium storing instructions that when executed by a computer cause the computer to perform a method for managing a distributed computer system having a group of nodes, each node having an identifier, and comprising a first and a second node being adapted to act as the current monitor node of the group of nodes, wherein the method comprises the following steps: a. requesting for an indication informing which one of the first or the second node acts as the current monitor node; b. attributing, to the current monitor node, the ownership of a list of associations address-identifier of nodes, this list comprising the associations from the first and second nodes; c. responsive to a reception of a request for an address of a requesting node in the first and the second nodes, associating and sending an address to the requesting node from the current monitor node; and d. repeating steps a. to step c. 